What makes C++ difficult?

I have used C++, on and off, since 2013. In that time I've gotten accustomed to what many would say is the difficult part - memory management. I personally do not find memory management difficult, but there are a few other things which consistently frustrate me and make my experience with C++ more difficult than it should be...

Building C++

In my opinion, the most difficult thing you have to deal with as a C++ programmer is the build. The sad state of the C++ build is due to many historic accidents, and even though there are attempts to make it better, it still sucks.

There are billions of lines of C++ in production, and many people who use C++ are used to builds being difficult. Even if things did change for the better I'm not confident this change would be widely adopted any time soon.

You can get a real appreciation for how messed up C++ builds are, if you use any new C-like language, like: Jai.

I think, the best way to deal with the C++ build is to get comfortable with a build tool like CMake. It's a necessary evil, it's weird and buggy, but at least it's IDE agnostic and you can do anything you want with it. Trick of-course, is to stop yourself before you make the build much more complicated than it needs to be.

Swiss Army knife of programming languages

C++ is a multi-paradigm programming language, meaning you can write fully procedural C-style code, or fully Object Oriented code, or even some bits of functional code. There's no problem in either style, but rather their co-existence within 1 programming language.

Because C++ needs to support all of these paradigms, two separate C++ projects can look as if they were written in completely different programming languages. In practice, this means that as a C++ programmer you need to be comfortable or at least tolerate these different ways of programming.

I'm somewhat good at dealing with this diversity of opinion in C++ community because I've written C++ on the both ends of the spectrum. I've written purely procedural C++, and purely object-oriented C++. Personally, I don't think it's practical to learn all of C++, it's better to learn features when you need them and adapt to what you team agrees to. Every C++ team is using some subset of C++ anyways.

Terrible error messages

Most of C++ error messages are cryptic, especially when dealing with templated types. Some are so cryptic that people used tools like: STLFilt to read them.

This problem is at the core of C++, all you can do is hope that C++ committee and compiler developers prioritize better error messages over some feature which covers some super rare use-case. Another thing you can do is: make your error messages good, avoid adding to the problem.

Clever landmines

Another difficult thing about C++ is that the language is so powerful, you can generate an infinite field of landmines for you and your team to step on, without even knowing it. This is true for many programming languages, however due to the context in which C++ is used, making such mistakes in C++ can lead to much worse consequences.

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off".

Yes, I said something like that (in 1986 or so). What people tend to miss, is that what I said there about C++ is to a varying extent true for all powerful languages. As you protect people from simple dangers, they get themselves into new and less obvious problems... (continued.)
- Bjarne Stroustrup

The way I interpret this, based also on my experience is that Cleverness is the root of all evil. C++ gives you the expressive power of more dynamic, garbage collected languages but without all of the safeguards. So its in your best interest to make your intentions known in your code. You do not want to force your team to guess what your code does.

Foo a = 4.2f;
a = 10;

There's nothing preventing us from making the code above do something strange like so:

struct Foo {
    float value;

    Foo(float value) {
        Workers::init((int)value);
    }

    Foo&
    operator=(int n) {
        Workers::start_thread(n);
        return *this;
    }
};

This obviously contrived example exists to highlight the real problem. It's not lost on me that programming is fun, and pushing the language to its limits is part of the fun. But this should not happen in the professional setting. It's better to write "dumber" code, which more clearly communicates intent, than show off with fancy usage of language features and mislead your team.

The best case outcome when working with "clever" code is time wasted, the worst case is a Heisenbug of catastrophic proportions, side effects of which are gracefully handled and thus nobody can dig it out until it's in production and it's too late. If the worst case does happen I hope this code is not running on an airplane.

Obviously a lot of these problems can and should be prevented with a document which defines the house rules for your team, as well as a good review process with people who take time to check if something strange was introduced to the code-base. Even just a rule of thumb - "Do not show off" should be enough.

I still like it

My criticism of C++ is not based in distaste for the language. In fact C++ is one of my favorite programming languages, and I enjoy the work I get to do with it. I criticize C++ because I want it to be better, and if I could fix one thing - it would be the build.